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FOREWORD 


The Constellation Program, as a national-level undertaking, had multiple purposes. These can 
and will be described from many points of view. 

To us Constellation was born of the charred debris, scattered in the Piney Woods of East 
Texas, that were reverently collected as the last remains of that delicate machine Columbia, she 
that failed to preserve the lives of our friends and colleagues due to our own very human errors. 
The painful acknowledgement of those errors became foundational principles for what later 
emerged as the nation’s new space exploration program: Constellation. 

For those of us who worked it, the program bound us by a common belief that America’s future 
lies in the Final Frontier; indeed that America must lead the way there. We joyfully dedicated our 
working lives and careers to building the ships that would sail those treacherous seas. We had 
prepared ourselves for this challenge, having learned from the best and honed our skills in the 
unique arena of human space flight. We were driven by the hope that America would one day 
step beyond the known, and were blessed when, for a moment, the national will bent towards 
our dreams. It was a privilege and an honor to have a hand in this endeavor. Perhaps our 
greatest shared joy and satisfaction came from the recognition that amid the inherent tumult of a 
program of this size and scope, we bore the challenges with teammates of superior skill and 
dedication. We understood that another generation would explore using what we had conceived 
and built. We rejoiced at our successes, but we also knew faults and failures. This, the 
summation of what we have learned, is our final expression of that cherished hope. 

To our families, we beg your forgiveness for the long hours away and too many distracted 
conversations. Thank you for indulging our passion. 

And, to our generational forebears in human space flight, our hope is that our efforts honor you. 
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PREFACE 


“Experience keeps a dear school, but fools will learn in no other. ”—Benjamin Franklin 

Learning from experience is irreplaceable. Learning from the experience of others is the next 
best thing. Both are an exercise in judgment. Sifting the useful kernels in a chaos of chaff 
requires perception and oftentimes detachment. We have attempted to present these lessons in 
a manner that allows this, and a format that can enable rapid learning in this context. 

This document (Volume I) provides an executive summary of the lessons learned from the 
Constellation Program. A companion document (Volume II) provides more detailed analyses for 
those seeking further insight and information. 

In this volume, Section 1.0 introduces the approach in preparing and organizing the content to 
enable rapid assimilation of the lessons. Section 2.0 describes the contextual framework in 
which the Constellation Program was formulated and functioned, which is necessary to 
understand most of the lessons. Context of a former program may seem irrelevant in the heady 
days of new program formulation. However, readers should take some time to understand the 
context. Many of the lessons would be different in a different context, so the reader should 
reflect on the similarities and differences in his or her current circumstances. Section 3.0 
summarizes key findings, at the program level, developed from the significant lessons learned 
that appear in Section 4.0. Readers can use the key findings in Section 3.0 to peruse for 
particular topics, and will find more supporting detail and analyses in a topical format in Section 
4.0. Appendix A contains a white paper describing the Constellation Program formulation that 
may be of use to readers wanting more context or background information. 

The reader will no doubt recognize some very similar themes from previous lessons learned, 
blue-ribbon committee reviews, National Academy reviews, and advisory panel reviews for this 
and other large-scale human space flight programs; including Apollo, Space Shuttle, Shuttle/Mir, 
and the International Space Station. This could signal an inability to learn lessons from previous 
generations; however, it is more likely that similar challenges persist in the Agency structure and 
approach to program formulation, budget advocacy, and management. Perhaps the greatest 
value of these Constellation lessons learned can be found in viewing them in context with these 
previous efforts to guide and advise the Agency and its stakeholders. 
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1.0 INTRODUCTION 


These lessons learned are part of a suite of hardware, software, test results, designs, 
knowledge base, and documentation that comprises the legacy of the Constellation Program. 

The context, summary information, and lessons learned are presented in a factual format, as 
known and described at the time. While our opinions might be discernable in context, we have 
avoided all but factually sustainable statements. Statements should not be viewed as either 
positive or negative; their value lies in what we did and what we learned that is worthy of 
passing on. 

The lessons include both “dos” and “don’ts.” In many cases, one person’s “do” can be viewed as 
another person’s “don’t”; therefore, we have attempted to capture both perspectives when 
applicable and useful. 

The lessons have been formatted with a description together with supporting information, a 
succinct statement of the lesson learned, and recommendations for future programs and 
projects that may be placed in similar circumstances. 

Supporting information, along with more detail on the Constellation Program, can be found in 
Appendix A and the companion Volume II. 
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2.0 CONTEXT — “WHERE YOU STAND DEPENDS ON 
WHERE YOU SIT” 


2.1 A Brief Description of the Program 

NASA formed the Constellation Program in 2005 to achieve the objectives of maintaining 
American presence in low-Earth orbit, returning to the moon for purposes of establishing an 
outpost, and laying the foundation to explore Mars and beyond in the first half of the 21st 
century. The Constellation Program’s heritage rested on the successes and lessons learned 
from NASA’s previous human space flight programs: Mercury, Gemini, Apollo, Space Shuttle, 
and the International Space Station (ISS). 

Following the loss of Columbia, NASA established the Columbia Accident Investigation Board 
(CAIB) to perform an in-depth review of the Space Shuttle Program. As a result of this review, 
the CAIB concluded that it was in the best interest of the U.S. to develop a replacement for the 
space shuttle. The CAIB concluded that it should be possible, using past and future investments 
in technology, to develop the basis for a system “significantly improved over one designed 40 
years earlier, for carrying humans to orbit and enabling their work in space.” 

In January 2004, The White House issued a new exploration initiative to return humans to the 
moon by 2020 in preparation for the human exploration of Mars and beyond. As part of this 
initiative, NASA would continue to use the space shuttle to fulfill its obligation to complete 
assembly of the ISS and then retire the space shuttle by 2010. NASA would also build and fly a 
new Crew Exploration Vehicle (since named Orion) by 2014. In 2005, Congress expressly 
endorsed the President’s exploration initiative and authorized NASA to “...establish a program 
to develop a sustained human presence on the moon, including a robust precursor program to 
promote exploration, science, commerce and U.S. preeminence in space, and as a stepping 
stone to future exploration of Mars and other destinations.” 

In response to the Presidential direction, the Agency formed the Exploration Systems Mission 
Directorate (ESMD) at NASA Headquarters in 2004 to oversee development of exploration 
programs. The Constellation Systems Division was initiated to oversee the human exploration 
mission development. 

In May 2005, the NASA Administrator commissioned the Exploration Systems Architecture 
Study (ESAS), a 60-day study to perform the task of defining the top-level requirements and 
configurations for crew and cargo launch systems to support exploration objectives. The study 
concluded that the launch vehicles should be derived from existing technologies, leveraging the 
lessons learned from past programs. The ESAS recommended an architecture that formed the 
basis of the Constellation Program. 

For those interested, Appendix A contains a paper that describes in more detail the rationale 
behind the formulation of the Constellation Program, including organizational structure and 
workforce structure, as well as the approaches to requirements generation, budget formulation, 
operational philosophies, and procurement strategies. 
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Since exploration of the moon and beyond was the overarching goal of the Constellation 
Program, all elements were designed to perform the lunar missions, while also being capable of 
performing missions to the ISS. The program was phased as a stepwise capability buildup that 
was largely based on space shuttle heritage components. The Initial Capability (1C) comprised 
elements necessary to service the ISS by 2015 with crew rotations: including the Orion Crew 
Exploration Vehicle, the Ares I Crew Launch Vehicle, and the supporting ground and mission 
infrastructure to enable these missions. The Constellation Lunar Capability (LC) added the Ares 
V Cargo Launch Vehicle, the Altair Lunar Lander, and spacesuits designed for partial-gravity 
exploration. Lunar Outpost elements and capabilities were to follow, including mobility elements 
such as rovers, permanent or semipermanent habitats, and power and communication elements 
to support a sustained exploration presence. 

The Constellation Program was managed at the Johnson Space Center (JSC), with the 
following seven “hardware development” project offices: 

• Crew Exploration Vehicle Project (the Orion spacecraft), at JSC 

• Exploration Launch Projects (the Ares / and Ares V launch vehicles), at the Marshall Space 
Flight Center (MSFC) 

• Ground Operations Project (development of launch and recovery facilities) at the Kennedy 
Space Center (KSC) 

• Mission Operations Project (development of flight and mission control facilities) at JSC 

• Extravehicular Activity (EVA) Systems Project (spacesuit and tool development) at JSC 

• Lunar Lander Project (the Altair lunar descent and ascent module) at JSC 

• Lunar Surface Systems Pre-project (advanced planning for lunar habitats and surface 
support systems) at JSC 

Orion, Ares I, Ground Operations, Mission Operations, and EVA comprised the 1C projects. Ares 
V, the Altair and Lunar Surface Systems, along with upgrades to the 1C to meet lunar interfaces 
and requirements, comprised the LC projects. 

By 2010, all elements of the 1C had achieved Preliminary Design Review (PDR), and test flights 
were under way, with the successful launches of Ares l-X and the Orion Pad Abort-1 tests. The 
White House announced the cancellation of the program on Feb. 1, 2010, on the seventh 
anniversary of the loss of Columbia and her crew. 

According to the NASA Authorization Act of 2010 (PL 111-267, Oct. 11, 2010), elements of the 
Constellation Program will continue in NASA’s current planning. The Orion vehicle is redesigned 
as the Multi-Purpose Crewed Vechicle (MPCV) and will likely enable crew launch on a variety of 
launch vehicles. The Space Launch System (SLS), intended as the vehicle to launch crews and 
cargo beyond Low Earth Orbit (LEO), has various configurations under consideration including 
options based on space shuttle and Ares heritage designs and hardware. The Ground 
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Operations infrastructure at KSC, developed for Constellation, will be adapted to the SLS and 
new commercial launch capabilities. 

2.2 The Program Environment — Key to Understanding the Lessons Learned 

2.2.1 Program Scope 

The Constellation Program was conceived as a multi-decadal undertaking, with the primary goal 
of enabling human exploration beyond LEO. It was to serve as the space shuttle’s successor 
not only in function but also in utilization of facilities and work force. It was to provide the primary 
mode of delivery of crews to the ISS, enable the construction and operation of an outpost on the 
moon, and enable human exploration of Mars. Constellation, as the Agency’s flagship program, 
spanned all 10 NASA centers and multiple large-scale acquisitions. It required modernizing an 
infrastructure that had been designed and sized largely for the Apollo Program in the 1960s. 
Moreover, it required leading a work force that was generationally removed from the previous 
human spacecraft launch and entry development challenges. 

While the near-term focus of the program was providing crew transport to the ISS via the 1C, the 
capability to go beyond LEO drove many of the technical and programmatic decisions. These 
decisions were suboptimal when viewed with only near-term objectives in mind, while they were 
necessary to support the LC phases of the program. They also, in some cases, increased risk to 
the 1C through incorporation of newer technologies with less flight heritage. The need for 
commonality to decrease life-cycle cost and complexity drove many decisions. For example, the 
Ares I design used a five-segment, solid-chemical first stage along with the J2-X upper stage 
engine. Other simpler, less-costly designs could have been used to optimize development for 
the Ares I alone, but, in context with the Ares V development, these elements lowered the 
overall program design complexity, risk, and cost. 

Optimization for the long-term program drove not only design decisions but also infrastructure 
needs, standards, organizational structure, units of measure (SI), data architecture, etc., that 
would not have been necessary for the 1C alone. The primary objective of stepping beyond LEO 
with the LC was optimized at the expense of having an 1C that was more costly and complex 
than necessary as a stand-alone development. 

2.2.2 Program Funding 

Funding for the Constellation Program was inconsistent and unreliable from its initial formulation 
through its cancellation. Indeed, this inconsistency became the chronic constraint that 
aggravated all other constraints. Figure 1 illustrates this persistent problem. The program 
experienced a 10% budget cut prior to PDR. The “profile” was far less than optimal for a 
development project. The funding “notch” in fiscal year 2010 (FY10) was a result of Agency 
funding limitations due to space shuttle retirement. While Constellation was expected to 
transport crews to and from ISS soon after space shuttle retirement, the funding ramp-up 
needed for development was not available until after the space shuttle was retired. This, of 
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course, put pressure on the program content, schedule, and rationale for the ISS crew rotation 
mission (Initial Operational Capability [IOC]). 



RY$ In M 
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FY09 
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FY14 
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Fig. 1: Constellation budget profiles before and after budget reductions (ESAS=the initial program 
budget baseline; PMR=Program Manager’s Recommendation; PBS=President’s Budget Submittal) 

Figure 2 illustrates the result of the budget pressure on major schedule milestones (PDR, Critical 
Design Review [CDR], IOC, and human lunar return [HLR]). IOC moved 2 years (2012 to 2014) 
due to the first budget cut. The program was able to recapture 1 year of that loss by replanning 
(at greater risk). Subsequent budget cuts pushed IOC further, into 2015. The program was 
required to hold the IOC schedule commitment to 2015, since this was the “no later than” date 
that was committed to Congress. 
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Fig. 2: Consequences of funding cuts on Constellation major milestones 

The phasing of the program exacerbated the funding challenges, in a “rob Peter to pay Paul” 
fashion. The viability of the lunar program phase was under constant threat, as it was the only 
souce to supplement shortfalls in the 1C when schedule slips had been exhausted (see effect of 
the fixed-base costs, below). The lunar phase of the program (e.g., HLR in Fig. 2) bore the brunt 
of the cuts that could be accommodated in out-years and was pushed even further than the IOC 
milestones. This is illustrated in Fig. 2 (observe that IOC was “held” in 2015 while PILR slipped 
almost 2 years). 

Constellation was planned with adequate budget reserves, although these reserves were not 
phased to be most useful to the program (i.e., much of the reserve was phased later in the 
program schedule rather than earlier). An unfortunately prevalent perspective on program 
reserves in the federal government is that reserves are seen as “over funding” that can be 
depleted to address other issues or drawn back to the Treasury if unused within 1 fiscal year. 
Agency reserves (i.e., allowance for program adjustment [APA] funds) had been long ago 
eliminated. Constellation reserves were intially planned to fund risk mitigation efforts. Reserves 
were rapidly depleted due to the combined effects of budget cuts, Agency “taxes,” and efforts to 
hold schedule without sacrificing content. Subsequently, risk mitigations were reduced and then 
eliminated, leaving little recourse to resolve the typical technical challenges that crop up in a 
design of this magnitude and complexity. Risk accrued as a result. 

The large acquisitions for design and construction of the major components of the program were 
planned, sized, and budgeted early in the program, as was neccessitated to meet schedule 


Vol. I Executive Summary 


Page 6 






























































































































Constellation Program _ Lessons Learned Volume I 

objectives. The prime contractors’ costs typically ramped up in accordance with plan. These 
costs were comprised of both ’’fixed-base” elements (work force, test facilities, etc.), and 
variable elements. As the program dealt with subsequent budget cuts, the fixed-base elements 
were extremely difficult to reduce; cuts tended to be absorbed within the variable elements (e.g., 
deferred hardware buys). This led to a number of problems: it increased schedule risk as more 
activities crept onto the critical path; it deferred activities planned to reduce risk, delaying risk 
mitigation strategies and increasing overall risk; and it also became an exercise in diminished 
returns — fewer and fewer items remained in the variable elements of the budget to defer in the 
next round of reductions. 

With the retirement of the Space Shuttle Program looming, great pressure was exerted to 
assimilate as much of the shuttle-heritage “fixed base” (e.g., work force, infrastructure, and 
industrial base) from that program as possible, per direction NASA received in two Authorization 
Acts (2005, 2008). While the operational requirements and sustaining budget planned for 
Constellation were smaller than that of the Space Shuttle Program, nearly every component, 
building, fleet, process, and cadre of workers had its advocacy group to sustain it. Because of 
the phasing of the Constellation Program, much of the infrastructure was not needed for the 1C 
but would be needed for the LC. This created an Agency-wide phasing challenge for these 
assets: retire/mothball the asset, or sustain it for many years unused? 

The tight coupling of the space shuttle retirement to the buildup of the Constellation 1C, along 
with the necessity to plan the 1C and LC with a large degree of commonality, made sense 
strategically when the plan was developed, but only if all of the schedule and funding 
assumptions held. The rationale did not withstand subsequent budget pressure and 
consequential schedule slips. 

While the Constellation Program hardware development budget was also large in an absolute 
sense at the Agency level, it was not yet operational (as space shuttle and ISS), so it was often 
perceived as the only source for unexpected expenses that cropped up in the Agency. Indeed, 
expenses were charged to the program that had no benefit to the program. This is not atypical 
for flagship programs in governmental developments. 

Cash flow disruptions, resulting from Congressional continuing resolutions (CRs), had been an 
occasional source of funding problems for the Agency in the past. During Constellation’s 
lifetime, these became annual events that many times lasted well into the new fiscal year. While 
these are experienced government wide, they are particularly onerous on developmental 
programs in early stages when funding levels are increasing toward their peak. A typical 
program “ramp-up” is nearly impossible during a CR. These funding shortfalls sent annual 
“square waves” of additional re-planning through the program, projects, and contractor 
communities. These were never fully attenuated through the remainder of the fiscal year. 

The Constellation Program content, constituted by the elements of the program architecture 
along with their associated performance requirements, was held as a higher priority than 
schedule performance by the Agency leadership; therefore, in the budget environment framed 
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above, schedules slipped, risk accrued, and reserves were depleted before serious 
consideration was given to de-scope program content. 

2.2.3 The Mosaic of NASA Participation 

As Constellation was the flagship program for the Agency, project and program work was 
distributed across the Agency to support the concept of maintaining “10 Healthy Centers” (Fig. 
3). This distribution was planned at the Agency level. The concept was not sufficiently defined to 
satisfy either centers or the program in light of the space shuttle retirement. Details of the 
implementation were left to the program to sort out in consultation with center management. 
This resulted in a persistent tension between what was most efficient for the program vs. what 
was best for a particular NASA center to sustain or grow its current role. The nationwide team 
was probably larger than necessary, but it also covered “unused capacity” at some centers. The 
large teams at multiple locations led to instances of overlapping or unclear roles and 
responsibilities. Decisions to perform tasks “in-house” using on-site work force at a center vs. 
contracting the task out were often made at the center or project level, and were not optimized 
for overall program benefit. 

The involvement of all 10 NASA centers exposed cultural differences that had to be managed 
by a management team that was geographically removed. Each center had different 
requirements, procedures, and processes, which were documented at various levels of detail 
and constraint. While these were useful to each center, the Agency had not completed an effort 
to assure that they were consistent, non-duplicative, and noncontradictory. This was a particular 
burden on the contractor community since it was charged with identification and compliance 
with duplicative and sometimes contradictory requirements. The mismatch of design and 
construction standards among centers, along with demands from the “insight” work force at 
each center, was a worrisome burden for the contractors, constantly threatening their ability to 
meet schedule milestones and cost thresholds. NASA’s use of an independent technical 
authority provided yet another source of direction and, thus, confusion to the contractor 
community. Contractors had difficulty distinguishing final decisions coming from the Agency, 
since direction could come from the program or the technical authority. 

The industrial base used by the Space Shuttle Program and, to a lesser extent, the ISS 
Program was managed by a separate mission directorate at NASA HQ. Overlapping strategic 
interests among the three programs (e.g., facility usage, floor space, test stands) had to be 
resolved at the highest levels in the Agency (i.e., between mission directorates). 

The position of an Agency flagship program carried benefits as well. The program had access to 
the entire Agency knowledge base, along with skills and infrastructure. The program was 
viewed as high priority at all centers, since it represented a path to a sustainable and growing 
role in most areas of expertise. Engagement of nontraditional human space flight centers 
allowed the program to tap into unique skills, approaches, and facilities. The contractors 
benefited from NASA’s technical depth and expertise, along with access to unique facilities 
(e.g., engine test stands, large vacuum chambers). The early test flights, Ares l-X and Orion 
Pad Abort-1, demonstrated the benefits of multicenter teams. These projects were successful 
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early pathfinders in identifying and resolving the problems that could arise from a conflict of 
cultures in design, testing, and manufacturing. 
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Fig. 3: The Constellation distributed team 

2.2.4 Phasing of Project/Program Start-up 

Two of the primary projects, the Orion Crew Exploration Vehicle and the Ares Crew Launch 
Vehicle, were begun well in advance of the Constellation Program. This enabled rapid start-up 
and early results from each project. They functioned for some time without an integration 
function between them, which led to an eventual Program Integration (PI) function that was very 
lean by historical norms. 1 The rapid start-up enabled rapid contract competition. However, these 
contracts were not fully scoped for the physical and analytical integration that was necessary. 
They were instead focussed on the 1C, since trade studies had not been performed that would 
optimize an integrated architecture. These factors led to costly contract changes when the 
appropriate level of integration for a complete architecture was better understood. 

This approach also provided an additional integration challenge. The projects had formed 
requirements, budgets, design approaches, acquisition strategies, etc., that needed to be 


A typical large space flight program historically used approximately 10% to 15% of its budget for PI. The 
Constellation Program was relatively lean, spending 5% to 7.5% on these functions. 
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integrated retroactively. The late addition of the integrating functions had a long-term effect that 
was not fully resolved by the end of the program. Strategies that were in a collective self-interest 
for the program were extraordinarily difficult to implement due to the cost of contract changes. 
Examples of these include unit policy (SI vs. heritage units of design and construction), data 
architecture, and facilities management. Boards and panels formed prior to the program office 
had different structures and responsibilities. Integration of these into a program board and panel 
structure confounded decision making. Moreover, integrated analyses by the program 
uncovered technical issues that could have been caught earlier (and been resolved in a more 
efficient manner) if the start-up timing had been different. 2 

Incentives on contracts were developed primarily to benefit each project rather than the overall 
program. Missing were incentives for contractors to participate in technical solutions that benefit 
the integrated program. This drove results that were less than optimum, and sometimes not 
mutually compatible. 


2 

An example of this is what became known as the “thrust oscillation” issue. Integrated analyses indicated 
that unacceptably large thrust oscillations from the Ares / first-stage burn could be transmitted through the 
stack to the flight crew in the Orion vehicle during launch. Design changes were implemented in the PDR 
time frame to mechanically dampen the oscillations and sufficiently isolate the crew. We can speculate 
that earlier identification could have resulted in simpler, lower cost changes. 
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3.0 KEY FINDINGS 


Given the challenges described in Section 2.0, the following is a brief listing of the key findings 
distilled from the Constellation Program. Explanatory information can be found in Section 4.0, 
and further detail is contained in Volume II. This list is hot linked to explanatory information in 
the electronic version of this document. 

The character of these lessons is worth noting. The reader will observe that very few technical 
issues arose that could not be solved in relatively short order; rather, the most difficult and most 
persistent challenges involved cost, schedule, and organization. The reader will no doubt 
recognize this pattern from previous large-program lessons learned. While the Agency is 
renowned for its technical prowess, senior managers in flagship programs can be faced with a 
multitude of nontechnical challenges for which they have far less training or preparation. In this 
respect, lessons learned can be an invaluable source of insight. 

• Robust vs. optimal planning—the only certainty is that funding will not match the plan 

• Schedule creep and the fixed base—the law of diminishing returns 

• Tailoring and the design and construction standards—drinking from a fire hose 

• Tailoring process simplification—the law of unexpected consequences 

• Risk-informed design—risk as a commodity 

• In-house tasks—sustaining the NASA institutional base vs. affordably supporting the 
programs—getting from “or” to “and” 

• Roles, responsibility, and authority (RRA)—a non-thermodynamic application of 
entropy 

• Decision making—is only as efficient as RRAs are clear and understood 

• Organization is organic—you will never get it right, but you can make it better 

• Communication among a far-flung team—interpersonal networks and information 
technology (IT) applications can improve bandwidth 

• Flight tests—learning by doing 
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4.0 LESSONS LEARNED 


4.1 Robust vs. Optimal Planning — The Only Certainty Is that the Funding Will 
Not Match the Plan 

Driving Events 

Section 2.1 describes the context and driving events for the funding and planning challenges 
faced by the Constellation Program. Constellation found itself in a grounds-up re-plan at least 
annually. 

Lessons Learned 

The reality is that Agency flagship programs like Constellation must be robustly planned (e.g., 
“elastic”) vs. optimally planned (“inelastic”). Absent a national imperative akin to the race to the 
moon, funding will not arrive as planned. Flagship programs are highly visible and stand alone 
in the national-level budget debates. As they are not part of a budget portfolio, they cannot look 
elsewhere for funding. 

A flagship program will never experience complete alignment of the budget with the plan, either 
in net or in phasing. Therefore, flagship programs should resist the urge to optimally plan each 
budget line item. 

Recommendation 

Plan for CRs for the first quarter of each fiscal year until and unless Congressional processes 
change substantially. 

Decouple programs/projects as much as possible in strategic, programmatic, and technical 
aspects. 

Proactively determine sensitivities and breakpoints in budgets, and communicate these to 
stakeholders a priori. Establish expectations for funding reductions in advance. This is the best 
hope to influence budget decisions. 

Develop scenario(s) to accommodate 5% to 10% funding shortfalls in any given fiscal year. 
Understand the major drivers to cost and options available (i.e., “the knobs to turn”) when 
unexpected challenges appear. 

4.2 Schedule Creep and the Fixed Base — The Law of Diminishing Returns 
Driving Events 

As discussed in Section 2.2, the Constellation Program dealt with funding cuts primarily through 
schedule slips rather than content reductions (due to NASA Administrator direction). Variable 
costs are early targets, since they can be deferred (while adding program risk). The fixed-base 


Vol. I Executive Summary 


Page 12 







Constellation Program _ Lessons Learned Volume I 

costs — both within the Agency and for the contractors — become proportionally larger, making 
schedule slips less and less effective in addressing cost cuts. 

Lessons Learned 

Each schedule slip resulted in longer periods for which Constellation was expected to maintain 
the Agency’s human space flight “fixed base” along with the industrial fixed base from its suite of 
acquisitions. This had the effect of reducing the overall cost savings being sought from the 
initiating event — the funding cut. A vicious cycle was established that only grew more severe 
during the life of the program as more and more time supporting the fixed base was added to 
the program lifetime. Ultimately it could not be resolved without addressing content reductions. 

Recommendation 

Understand the inherent limitations of schedule slippage to resolve funding shortfalls, since 
accrual of the fixed-base portion of the budget erodes the buying power in out-year funding. 
Reduction of program content warrants consideration under these circumstances. 

4.3 Tailoring and the Design and Construction Standards — Drinking from a 
Fire Hose 

Driving Events 

The involvement of the 10 NASA centers (described in Section 2.2.3, Mosaic of NASA 
Participation), along with the overabundance and over-prescriptive nature of design and 
construction standards led to an avalanche of “shall” requirements on the Constellation 
contractors. While Constellation was allowed broad latitude to tailor requirements, such tailoring 
required rationale and negotiation with the requirement “holder.” The sheer number of direct and 
embedded requirements made the task of tailoring intractable. 

The following illustrates the extent of the problem: 

• The Orion prime contract alone levied design and construction (D&C) specifications 
from: 34 NASA standards, 10 Johnson (Space Center) Program Requirement (JPR) 
documents, 11 JSC technical standards, 3 NASA Program Directives (NPDs), 6 NASA 
Program Requirements (NPRs), and 11 KSC standards. These included: 

o NASA STD 8739.3, Soldered Electrical Connections - a 93-page document with 
391 “shall” statements inclusive of room temperature/relative humidity and 1077 
lumens of light per square meter or 100 foot candles on the work surface, 
o NASA STD 8739.4, Crimping/Cables/Harnesses/Wiring - a 66-page document 
containing 391 “shall” statements requiring a (a) Snell far-vision chart 20/50; (b) 
near-vision Jaegerl @ 355.6 mm; and (c) reduced Snell 20/20 or equivalent. 
Requires color vision testing and specifies temperature/humidity and lighting, 
o NASA STD 8719.9, Standard for Lifting Devices - a 126-page document 
containing 996 “shall” statements covering use of overhead devices and powered 
and motorized devices; it also approves the use of manufacturer’s procedures 
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and provides instruction on how to set the parking brakes on mobile and 
motorized units. 

All of the major aerospace contractors, who build systems for multiple government customers 
(Department of Defense (DoD), National Security Agency (NSA), NASA, etc.), have certified 
internal processes and suppliers that meet both national and international standards. The set of 
NASA requirements is often redundant to this. 

Lessons Learned 

The massive quantity of D&C standards defies tailoring for even a large program such as 
Constellation. Major aerospace contractors have sufficient processes such that NASA’s D&C 
standards are of questionable value. This is a major driver of program-fixed costs. 

Recommendation 

NASA should assume the burden of “meets or exceeds” evaluations on itself instead of making 
the contractor prove it meets NASA requirements. NASA should implement this by establishing 
an experienced team to audit contractor internal processes at the NASA document level. This 
process should not burden the contractor with defending the adequacy of each individual 
requirement. For the most part, the aerospace contractor community is well versed in the 
appropriate manufacturing and safety measures required to develop space hardware. NASA 
should build on that expertise. 

Currently, this topic (Affordability/Innovation) is the subject of discussion among the Chief 
Engineer’s Office, the Office of the Chief Health and Medical Officer, and Safety and Mission 
Assurance (S&MA) leadership. A team has been tasked with describing a process and timeline 
for transforming the Agency approach to Technical Authority requirements and standards. This 
initiative should establish clear criteria for mandatory (“shall”) requirements. It should also 
revalidate the Agency’s current requirements base with the goal of significantly reducing the 
total number. Most requirements should become guidelines or best practices. 


4.4 Tailoring Process Simplification —The Law of Unexpected Consequences 
Driving Events 

One of the many findings of the CAIB was that NASA had institutionalized the waiver and 
deviation process for requirements such that permanent or semipermanent waivers and 
deviations to requirements were the accepted norm. The CAIB, and other committees and 
panels studying the NASA human space flight culture, questioned the quality and validity of 
requirements that need permanent waivers or deviations to remain extant. Consequently, the 
need to establish a waiver or deviation developed an understandable cultural taint in the work 
force. Training after the Columbia accident reenforced this aversion. Indeed, important NASA 
stakeholders (e.g., Congress, the Aerospace Safety Advisory Panel, members of the public) 
were keen to maintain visibility on NASA’s use of waivers. 
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Meanwhile, the Agency did not grapple with the plethora of requirements that drove the practical 
need for waivers and deviations to requirements. While the Agency approach to requirements 
was redesigned with the introduction of the independent Technical Authority, the actual number 
and scope of requirements was not addressed. 

This left the Constellation Program in a quandary. While the Constellation Program was allowed 
broad latitude in tailoring requirements to its needs, the Agency decided that the program would 
use deviations and waivers to document tailoring outcomes. Cultural consequences were not 
evaluated. Moreover, the process for permanent deviations and waivers was formalized by the 
Agency. Discussions of tailoring were driven down to the level at which they were most 
productive — to those most familiar with design and implementation. However, waivers and 
deviations required higher visibility within the Agency to agree on. This cultural inconsistency, 
coupled with the sheer number of requirements addressed in the previous lesson, made the 
tailoring process nearly insurmountable. 

Lessons Learned 

While the use of waivers and deviations was intended to simplify the tailoring process of 
requirements for the Constellation Program, the cultural consequences were not addressed. 
This had the unintended consequence of confounding the tailoring process rather than assisting 
it. 

Recommendation 

Tailoring of requirements is necessary and should not carry a cultural stigma. The process 
should be revised to remedy the negative implication. 

4.5 Risk-informed Design — Risk as a Commodity 

Driving Events 

The broad scope of the Constellation Program permitted, to great effect, some experimentation 
in the design process. The traditional aerospace design process (i.e., the “rule-based” 
approach), wherein the vehicle is designed strictly to requirements (and, by implication, all 
requirements are equal or nearly so), was used on most elements. Two elements employed a 
risk-based approach that resulted in overall better designs. 

The Orion vehicle was designed initially using the rule-based approach. In meeting all 
requirements, the vehicle was overly constrained, was too heavy, and had performance 
challenges. To “close the architecture,” the project implemented a revised design process that 
prioritized mission-critical, reliability, and safety requirements. A “zero-based” vehicle was 
designed that met only these requirements. All other design features required justification based 
on an ability to reduce risk, i.e., risk as a commodity, using standard risk assessment tools (e.g., 
probabilistic risk assessment, hazard analysis, and failure modes and effects analysis) along 
with the beneficial use of other design commodities (e.g., power, mass, budget). The ability of 
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the Orion vehicle to minimize LOC (loss of crew) probability, along with meeting of performance 
and mass constraints, was improved through application of this process. 

The Altair vehicle pioneered a similar approach, which was uniquely applied a priori. The Risk 
Informed Design Process used an analysis-based approach to design the absolute minimum 
vehicle necessary to perform the mission and then added design features by proven value in 
increasing vehicle reliability and safety. This resulted in more robust design solutions that either 
eliminated or better-controlled hazards. 

Lessons Learned 

Risk Informed Design (i.e., treating risk as a commodity in design) was a breakthrough for both 
Orion and Altair, resulting in designs that “closed” and were safer and more reliable than a “rule- 
based” design approach could yield. 

Recommenda tion 

A rule-based design approach can remove accountability for understanding the implications of 
design choices. Employ risk-informed design methodology a priori to focus design on overall 
mission success rather than compliance with “design rules.” 

4.6 In-house Tasks — Sustaining the NASA Institutional Base vs. Affordably 
Supporting the Programs — Getting from “or” to “and” 

Driving Events 

The driving events for this lesson are described in Section 2.2.3 under “Mosaic of NASA 
Participation.” 

While the Constellation Program attempted to distribute work in logical packages, the competing 
needs of “10 Healthy Centers,” the scope of the program, and phasing considerations (e.g., 
placement of work in the post-shuttle era) drove instances of incoherent distribution, resulting in 
muddling of roles, responsibility, and authority. 

An example of the Orion Launch Abort System (LAS) development further illustrates the wide 
distribution of roles and responsibilities. This development was a subsystem of Orion and is not 
an extreme example, but it is typical of the rest of the program. Responsibilities were divided as 
follows: 


• JSC: Orion project management, lead for crew module and vehicle integration, prime 
contractor oversight, and independent analysis 

• MSFC: LAS prime contractor oversight and independent analysis 

• Langley Research Center: Lead for LAS integration, prime contractor oversight, and 
independent analysis 

• Glenn Research Center: Flight Test Article and pathfinder production for service module 
and spacecraft adapter 
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• Dryden Flight Research Center: Lead for Abort Flight Test integration and operations 

When everybody is responsible for everything, nobody is responsible for any one thing. 

Furthermore, the relatively low cost of most in-house tasks can be deceiving. While sometimes 
low in cost, the price of confused RR&A can lead to major headaches that flow into the 
contractor infrastructure. These roles are often coupled with the desire for modernization of 
associated host center facilities, which can drive larger costs. 

Lessons Learned 

Task assignments for in-house work are strategic drivers within the Agency; they are more than 
a series of make-buy or in-house vs. contractor decisions. Clear RR&As must be a priority. In 
spite of the relative low cost, the distribution and RR&A for in-house tasks are deserving of 
management focus to avoid confusion and overlapping roles down the line. 

Recommenda tion 

Target in-house tasks for items that mutually benefit programs (e.g., unique expertise) and 
centers (e.g., institutional sustainment). Due diligence will be needed to achieve this balance of 
benefit to the program and benefit to the NASA institution. A balance will bring value to the 
program as well as provide strategic support for the NASA institution, equipping the Agency to 
accomplish future programs and missions. 

Affordability, institutional benefit, and coherence of RR&A should be three additional strategic 
considerations in these decisions. Simply said, make sure the gain is worth the pain. 

4.7 Roles, Responsibility, and Authority — a Non-thermodynamic Application of 
Entropy 

Driving Events 

The clarity of RR&A for the Constellation Program was degraded by the combined effects of the 
wide distribution of program responsibilities via the “10 Healthy Centers” policy, multi-decadal 
phasing of the program development in 1C and LC, and assumption of traditionally understood 
roles from the space shuttle heritage component development as described in Section 2.2. 

The program undertook a number of steps to improve this, by conducting work force surveys 
and regular management retreats. Perhaps the most successful effort was the Program 
Excellence Team, a council of program deputies that frequently met face-to-face and via telecon 
to work through specific issues related to RR&A. 

Lessons Learned 

There is no formula or checklist for clear RR&A in an agency-wide flagship program. The 
specific approach on organizational structure taken by Constellation in this regard is addressed 
in Appendix A, in the paper on formulation of the program. Projects housed at centers in which 
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previous or similar work took or takes place will tend to assume these heritage roles in spite of 
contrary direction. 

Two early test flights provide examples of how strong leadership and imminent schedule 
milestones can drive improvements in RR&A and decision-making. 3 The Ares l-X test flight and 
the Orion Pad Abort-1 test flight were both pathfinders in how to function and succeed within the 
broad scope of the far-flung Constellation organization. Both were developed using distributed 
teams and hardware developments as the program relationships were forming. While initially 
hampered by the same factors described in this section, these teams were able to focus on the 
most important elements and succeed in meeting all of their test flight objectives. 

RR&A can be improved through functional examination or by either combining like tasks or 
separating functions by need. Implementation was hindered during the development of the 
Integrated Master Schedule (IMS) by the conflicting needs of the product/task providers and the 
schedule assessment team. When these functions were separated, IMS development quickly 
gained focus and results improved. 

Risk management was challenged because it was separate functionally from cost threat 
management. When broader aspects of risk (e.g., cost threats, safety, etc.) were included, the 
results from the system improved. 4 

RR&A for the 1C was relatively clear and in daily operation. Roles for the LC, while defined at a 
top level, were best developed for projects that had “follow-on” content from the 1C. 

The program was also contemplating the roles the International Partners might take. This 
formulation is described in Volume 2, for interested readers. 

Recommendation 

A good start is important to define RR&A; however, periodic examination is required for large- 
scope, distributed programs. Attention to the effects of heritage RR&A and phasing are 
particularly important. RR&A should also be planned to adapt to the program phase(s). 

Creating a dedicated team of decision makers (e.g., the council of deputies) to critically review 
and address RR&A can be very effective. 

Use of annual employee surveys provides a useful metric toward gauging the effectiveness of 
measures taken to address RR&A issues. 


3 See also the lesson learned in Section 4.11 for more benefits of test flights. 

4 NB: Risk management systems quickly degrade to “issues-tracking” unless adequate reserves are 
maintained to address and retire risks at the appropriate time. Lacking this, risks become accepted de 
facto. 
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4.8 Decision Making — Only as Efficient as Roles, Responsibilities, and 
Authorities are Clear and Understood 

Driving Events 

The clarity and effectiveness of the decision-making processes for the Constellation Program 
were driven by the same events as summarized in Section 4.7 and described in more detail in 
Section 2.2. 

The start-up phasing (late start of the program relative to the projects) previously described also 
confounded decision making. Projects made unilateral changes without considering integrated 
effects. For example, Ares made changes to the “stack height” that impacted the Orion and 
Ground Operations designs; Orion, without understanding the integrated effects, deleted a test 
flight that was found unnecessary. Once the program integration function was operational, 
decisions were better coordinated, but opportunities for early-phase, lower-cost changes were 
lost. 

The mature decision-making structure affecting Constellation Program decisions is partially 
illustrated in Fig. 4. Not shown are other organizations that have a significant influence on 
decisions: the center institutional processes (e.g., Engineering Review Boards, Program 
Management Councils, Facility boards), the Technical Authority (which provides the appeals 
route for technical decisions), and the internal decision processes for the prime contractors. 

Lessons Learned 

Despite constant attention from senior management, the decision-making process remained a 
persistent issue that only marginally improved over time. In a program of this scope, attempts to 
balance timely decision making at the appropriate levels, consider strategic and tactical 
viewpoints, and clearly delineate accountability for execution while keeping all stakeholders 
informed and included often left someone dissatisfied. The need to maintain the multi-decadal 
focus was sometimes misunderstood, particularly in projects with immediate, near-term needs. 

The need to make decisions regarding NASA center infrastructure that would or would not 
support Constellation over time was particularly nettlesome, bringing in communities that 
seldom dealt with program management. These decisions typically necessitated involvement at 
the Agency level and required extra time and staffing. Major infrastructure changes drew 
interest and attention from Congress as well, so it was necessary for many entities outside the 
program to be well informed. 
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Fig. 4: Illustration of the Constellation Program decision-making board and panel structure. Note 
what is not shown: center institutional decision making bodies, Technical Authority (the appeals 
process), and the prime contractors internal processes. (SSP=Space Shuttle Program) 

Recommendation 

A good start is important to define the decision-making process; however, constant vigilance is 
required for large-scope, distributed programs. Invest the time and energy to define a 
comprehensive decision-making process that includes all affected parties (Technical Authority, 
center management, and contractors). Impediments will arise by not anticipating key 
stakeholder interests. 

Attention to the effects of project phasing, particularly for decisions intended to last decades or 
affect center infrastructure, is very important. 
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4.9 Organization Is Organic — You’ll Never Get It Right, But You Can Make It 
Better 

Driving Events 

The organizational structure for the Constellation Program evolved over time. Initially the 
organization was set up in a model derived from the Apollo Program — an integration function 
comprised of Systems Engineering and Integration (SE&I), Test and Evaluation (T&E), 
Operations, Program Planning and Control, and Safety, Reliability, and Quality Assurance 
(SR&QA), 5 along with the individual projects including Ares, Orion , Ground Operations, Mission 
Operations, and EVA. An Advanced Projects Office was also included to begin formulation of 
the lunar projects, including the lander and surface systems. Significant changes within the next 
year included the following: 

• Establishment of mission managers for the Ares l-X and /-Y flight tests to enable the 
focus needed for integration 

• Establishment of the Lunar Lander Project ( Altair ) and the Lunar Surface Systems 
Project, and dissolution of the Advanced Projects Office in response to the completion of 
early formulation activities for these projects, and no immediate need for succeeding 
early formulation activities beyond the lunar missions 

In the following year, other organizational refinements were implemented: 

• Combination of the Test & Evaluation Office with SE&I, since the T&E role had become 
entangled with that of SE&I and the Ares l-X and /-Y mission managers 

• Establishment of the Program Architect to balance the maturation of the Constellation 
architecture (LC) with the near-term (1C) systems development. 

In the subsequent year, further organizational refinements were implemented: 

• SE&I was reorganized to transform its focus from requirements definition to design 
integration following completion of the program SDR. 

• The Information Systems Office was formed in response to the focus needed in 
development and implementation of a program-wide data architecture. 

The preceding listing is illustrative rather than comprehensive to communicate that the program 
adapted the organization over time to both emergent issues and task completion. 

Lessons Learned 

Organizations should be treated as organic entities, evolving and adapting to circumstances 
over time. Needed adaptation can be anticipated according to schedule milestones; the work 
force and organization should be focussed on achieving the next key milestone, not continuing 
to operate in the mode that achieved the last key milestone. Key milestones such as design 


5 

See Appendix A for further discussion of the organizational structure based on the Apollo Program. 
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reviews mark natural breakpoints in organizational strategies and, indeed, the organizational 
scheme warrants assessment as part of a key milestone review. Consider that as the 
Constellation Program moved from requirements definition to development the needed changes 
were not uniformly recognized, so the organization was slow to adapt after the Systems 
Definition Review (SDR) to prepare for the PDR. Rather than preemptively assessing the 
organizational model, the program leadership reacted to issues associated with progressing to 
the PDR as they emerged. The post-PDR organizational adaptation to CDR objectives was 
accomplished more quickly since it was anticipated. 

Recommendation 

Revisit the organization at key milestone reviews to address the changing nature of the work 
ahead to achieve the next milestone. This should be documented in a revision of the Program 
Plan and be briefed to senior Agency management at the appropriate milestone briefing. Senior 
Agency management must be enlisted to mitigate social impacts across NASA centers due to 
the ebb and flow of assigned work. 

4.10 Communication Among a Far-flung Team — Interpersonal Networks and 
Information Technology Applications Can Improve Bandwidth 

Driving Events 

As discussed in Section 2.2, Constellation’s widespread 10-center team created a true 
communications challenge. While countless assessments and prevailing programmatic wisdom 
indicate that a small, centrally located team is the most efficient way to build a complex element, 
Constellation did not have that luxury. This posed many RR&A and decision-making issues, as 
described above (Sections 4.7, 4.8, and 4.9) as well as integration challenges. Well-understood 
RR&A and clear decision-making processes reduce the communication “overhead” for the 
program team. Beyond that, any and all efforts to improve communications are beneficial. 
Constellation used the following to enhance communication over and above holding regular 
face-to-face meetings: 

• A council of project and program deputies, mentioned in Section 4.7, was formed to 
resolve issues related to roles, decision making, and communications. The council was 
formed in early 2007 to tackle issues already apparent in RR&A associated with the 
formation of the Program Office. This council became an informal communication 
network; members spent time with each other and gained trust by sharing perspectives 
and working through problems of mutual interest. 

• “Communities of Practice” were formed to foster discussions in particular technical areas 
and aid information flow. 

• IT tools and applications (telecon, WebEx [Cisco, San Jose, CA], LifeSize® [LifeSize® 
Communications, Inc., Austin, TX], ICE/Windchill, etc.) were all extensively used to 
enhance the flow of information. 
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Lessons Learned 

This thorny issue was a classic case of “the devil is in the details.” RR&As were clear enough 
overall, as everyone understood the integrating responsibility of the Program Office with respect 
to the constituent projects; however, translation of this overall understanding into day-to-day 
practice was needed to address the real issues that cropped up daily. 

As such, frequent meetings of the council of deputies were necessary, which gave the informal 
network an ideal opportunity to form. IT tools including telecon and WebEx allowed many virtual 
meetings to be interspersed with the face-to-face meetings, greatly increasing productivity of the 
group. Over time, as the relationships between group members grew stronger and the team’s 
norms of behavior became more ingrained in the team members, more and more of the group’s 
work could be accomplished via these virtual meetings, further increasing productivity. 

The council of deputies is but one example; the integration groups for each of various 
engineering disciplines also benefited from improved IT collaboration tools over the previous 
generation, allowing significant improvements in the utility of virtual team meetings. 

Recommenda tion 

Large-scope, geographically dispersed programs can benefit from interpersonal networks 
established across organizational boundaries. 

Affordable, state-of-the-art IT tools can facilitate communications across time and space. They 
should be available as early and as broadly as feasible. 

A large program should be diligent in anticipating the formal and informal networks that will 
emerge or intentionally be formed, and ensure that these networks have access to the IT tools 
that will enable them to work most productively. 

4.11 Flight Tests — Learning by Doing 

Driving Events 

The value of flight tests in program development is undisputed; however, they are inherently 
resource intensive — that is to say, expensive. As such, they are typically reserved as risk 
mitigation for significant technical risks and demonstrations of critical capabilities. For the 
Constellation Program 1C, flight tests were primarily focussed in two primary areas: Ares launch 
vehicle ascent performance and Orion LAS performance. 

The Ares l-X was the first test flight in a planned series that would culminate in human rating of 
the vehicle. It was designed as a crewless development flight test to demonstrate the first-stage 
ascent performance. Ares l-X successfully flew in October 2009, achieving all test objectives. 
One of the primary purposes of Ares l-X was to acquire flight data early enough to influence and 
impact the design and development of the Ares I. The Ares l-X attributes were sufficiently 
similar to the Ares I to meet the test flight objectives. The test provided enough data for partial 
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validation of models and processes used in the Ares I design, and allowed the test data to 
improve Ares I design and development. 

A series of flight tests was planned for the Orion LAS to certify safety and performance in the 
most challenging launch and flight regimes. The first flight test (Pad Abort-1) demonstrated LAS 
performance and crew module landing systems performance in a pad abort scenario. Pad 
Abort-1, which was launched in May 2010, was the second Constellation flight test and 
achieved all flight test objectives. A primary purpose of this launch, which was akin to that of 
Ares l-X, was to acquire flight data early enough to influence and impact the design and 
development of the Orion LAS and crew module landing and recovery systems. The test 
provided enough data for partial validation of models and processes used in the Orion design, 
improving Orion design and development. 

The Ares l-X and Pad Abort-1 efforts were largely independent activities. As such, comparing 
the two flight test activities reveals fundamental similarities that may characterize successful 
flight tests and provide insight for future program success. 

Lessons Learned 

Both flight tests were very successful, achieving all flight test objectives and returning a wealth 
of technical data early enough in the development cycle to inform design; however, the key 
lessons learned involve the nontechnical returns from the flight tests. In both cases, these 
complex flight tests stressed the needed organizational constructs and drove clarity into RR&A 
and the decision-making structures. Had these issues been revealed later and addressed 
nearer to first full-system flight (e.g., the planned Orion- 1 mission), significant delays and an 
increased risk posture would have resulted. 

Furthermore, nontraditional approaches can be tried during a flight test, particularly a crewless 
flight test. For instance, Ares l-X used a “ping-test” approach to determine the structural 
characteristics of the stack rather than a much more expensive and time-consuming structural 
ground test. This approach worked very well and, after its successful demonstration on Ares l-X , 
the program was examining the cost savings vs. risk of adopting this approach for future flights. 

Finally, it is noteworthy that when the program was cancelled, it was in the process of revising 
the development strategy for the 1C to rely more heavily on flight tests, saving time and budget 
by reducing ground tests in response to the increased confidence in the analytical models and 
simulations that resulted from the Ares l-X and Pad Abort-1 flight tests. 

Recommenda tion 

Plan a series of flight tests to demonstrate key system capabilities and mitigate major technical 
risks. Ensure that some of the flight tests occur early enough in the development cycle (i.e., 
PDR time frame) to return data in time to inform the system design. Flight tests have the 
additional benefit of providing opportunities to test alternative approaches and discover 
efficiencies for overall organizational performance. 
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5.0 DEVELOPMENT PROCESS, KNOWLEDGE CAPTURE, 
AND CONTRIBUTORS 


The entire Constellation Program team contributed to these lessons learned, in both the content 
of this Volume I Executive Summary and the content of Volume II. The knowledge capture 
process is described in Volume II. 

An executive review committee assisted in synthesizing the lessons learned. This committee 
was comprised of: Bob Ess (Ares l-X Mission Manager), Jeff Hanley (Constellation Program 
Manager 2005-2010), Deb Neubek (Constellation Chief of Staff—Technical), Charlie 
Stegemoeller (Constellation Deputy Program Manager and former Program, Planning, and 
Control Director), Dale Thomas (Constellation Program Manager and former Deputy 
Constellation Program Manager), and Teresa Vanhooser (Ares Project Manager, Ares 
Projects). A full list of contributors to Volume II appears in that volume. 

Dale Thomas, Deb Neubek, and Jennifer Rhatigan synthesized and structured these 
contributions into the Lessons Learned documents (Vol. I and Vol. II). 

The program and its projects conducted knowledge-capture activities throughout its duration. 
These included many Lean Six Sigma events, a multitude of technical reports, conference 
papers, and final lessons learned activities. All formal program documents, reports, review 
materials, lessons learned reports, etc., will be both archived with the National Archives and 
Records Administration and made available in the ESMD ICE system. 6 Those lessons learned 
that are deemed as key risks are being fully documented, via text and video interviews, as 
knowledge-based risks. In addition, hundreds of lessons learned are being entered into the 
NASA Engineering Network’s Lessons Learned Database. The ICE system will include a 
Constellation Program Knowledge Management wiki page that will link to the various topics to 
make finding all of these materials easier. 

Current URLs [uniform resource locators] for these resources are below: 

Exploration Systems Risk and Knowledge Management Portal: 

https://ice.exploration.nasa.gov/ice/site/km 

NASA Engineering Network (Click on the Lessons Learned Tab): 

https://nen.nasa.gov/web/nen 

Public NASA Engineering Network Lessons Learned: 

http://llis.nasa.gov/llis/search/home.isp 


In researching lessons learned from previous programs, primarily Apollo and space shuttle, a number of 
key documents were scanned into electronic form for wide distribution within the program and archived in 
the Constellation database. These documents are also available to interested readers. 
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APPENDIX A. PAPER ON PROGRAM FORMULATION 
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ABSTRACT 

NASA has recently formed the Constellation Program to achieve the objectives of maintaining 
American presence in low Earth orbit, returning to the Moon for purposes of establishing an 
outpost, and laying the foundation to explore Mars and beyond in the first half of the 21st 
century. The Constellation Program’s heritage rests on the successes and lessons learned from 
NASA’s previous human spaceflight programs: Mercury, Gemini, Apollo, Space Shuttle and 
International Space Station (ISS). This paper describes the rationale behind the formulation of the 
Constellation Program, including organizational structure, and workforce structure, as well as the 
approaches to requirements generation, budget formulation, operational philosophies, and 
procurement strategies. 

INTRODUCTION BACKGROUND 


NASA’s human spaceflight history of 
program formulation, development and 
operations was a primary resource in the 
formulation of the Constellation Program. 
We researched historical records from the 
Apollo Program, and its predecessors 
Gemini and Mercury, as well as the more 
recent Space Shuttle and ISS Programs. 
Most importantly, consultation not only with 
histories, but also with individual managers 
involved in key decision making in past 
programs, formed the basis of the structure 
of today’s Constellation Program. 
Moreover, much of the Constellation 
hardware traces its history to previous 
programs and that corporate history and 
existing management structure have been 
leveraged to a great extent. This paper 
summarizes the rationale for the Program 
structure. We note that current technical 
descriptions of the program content may be 
found elsewhere. 1 


Following the loss of Columbia, NASA 
established the Columbia Accident 
Investigation Board (CAIB) to perform an 
in-depth review of the Space Shuttle 
Program. As a result of this review, the 
CAIB concluded that it was in the best 
interest of the U.S. to develop a replacement 
for the Space Shuttle. The CAIB concluded 
that it should be possible using past and 
future investments in technology to develop 
the basis for a system, “significantly 
improved over one designed 40 years 
earlier, for carrying humans to orbit and 
enabling their work in space” 2 . 

In January 2004, The White House issued a 
new exploration initiative 3 to return humans 
to the Moon by 2020 in preparation for 
human exploration of Mars and beyond. As 
part of this initiative, NASA will continue to 
use the Space Shuttle to fulfill its obligation 
to complete assembly of the International 
Space Station (ISS) and then retire the Space 
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Shuttle by 2010. NASA will also build and 
fly a new Crew Exploration Vehicle (since 
named Orion) by 2014. In 2005, Congress 
expressly endorsed the President’s 
exploration initiative and provided 
additional direction 4 , authorizing NASA to 
“...establish a program to develop a 
sustained human presence on the moon, 
including a robust precursor program to 
promote exploration, science, commerce and 
U.S. preeminence in space, and as a stepping 
stone to future exploration of Mars and other 
destinations.” 

In response to the Presidential direction, the 
Agency formed the Exploration Systems 
Mission Directorate (ESMD) at NASA 
Headquarters in 2004 to oversee 
development of exploration programs. The 
Constellation Systems Division was initiated 
to oversee the human exploration mission 
development. 

In May 2005, NASA Administrator Michael 
Griffin commissioned the Exploration 
Systems Architecture Study (ESAS), a sixty- 
day study to perform the tasks of defining 
the top-level requirements and 
configurations for crew and cargo launch 
systems to support exploration objectives. 
The study concluded that the launch vehicles 
should be derived from existing 
technologies, leveraging the lessons learned 
from past programs. The ESAS 
recommended an architecture which 
included a Crew Launch Vehicle (since 
named Ares I) to ferry crew and cargo to the 
ISS and to carry crew to Earth orbit. A 
heavy-lift Cargo Launch Vehicle (since 
named Ares V), to support missions to the 
Moon and Mars was also defined. 5 The 
resulting architecture formed the basis of the 
Constellation Program. 

In August that year, the NASA 
Administrator formed the ESAS 
Requirements Transition Team (ERTT) 
charging them to complete an architecture- 
level specification that defined the elements 
and their top level functionality; and to 
complete a draft of the Crew Exploration 
Vehicle System Requirements Document, 
validating its consistency with the 
architecture and providing the basis for 
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subsequent prime contractor selection. It is 
also notable that the ERTT was asked to 
lead the first of many internal NASA 
cultural changes, including the adoption of a 
‘zero-based’ requirements philosophy, in 
which only the minimum necessary and 
cost-effective requirements are included. 

CONTEXTUAL DIRECTION 

No modern program is created from whole 
cloth, and the Constellation Program is no 
exception. We note here the major themes, 
forces, situations, guidelines, constraints and 
environmental considerations underway at 
the time of the Constellation Program 
formulation. These are provided for 
contextual understanding of the Agency 
expectations of the Program. 

Continue Human Spaceflight 
The Agency’s primary objectives are 
continued safe operations of the Space 
Shuttle and completion of the ISS. The 
human space flight work-force within the 
Agency is engaged in continuous operations 
in support of those objectives. 

Transition the Space Shuttle 
With the retirement of the Space Shuttle 
planned for 2010, the Constellation Program 
should plan to utilize the Space Shuttle 
workforce, hardware and infrastructure that 
support the Constellation mission, in a 
manner that enables a smooth transition 
from one to the next, but does not interfere 
with on-going operations. 

Plan for Level Budgets 
The Constellation Program should expect 
the Agency’s allocation of the Federal 
budget to remain at levels consistent with 
the current environment. No increases other 
than modest cost-of-living increases should 
be expected, thus the Constellation Program 
development is constrained by completion 
of the Space Shuttle Program. 

Lead an Agency-wide Team 

The Constellation Program should leverage 

expertise across the Agency where possible, 
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in keeping with Agency objectives to 
maintain all 10 NASA Centers in healthy 
posture. Indeed, the Program should 
transform the 10 NASA Centers into a 
unified agency-wide team. 

As the Crew Exploration Vehicle and the 
Crew Launch Vehicle organizations were 
previously formed in the Fall of 2005, the 
Constellation Program should establish a 
strong program to lead the integration of 
these established organizations. 

Lead Culture Change 

The Space Shuttle and ISS Programs were 
developed in the context of their times, 
facing challenges and unknowns that 
humble us in appreciation of the efforts it 
took to make them successful. There is an 
inherent legacy to efforts of that magnitude; 
some appropriate for direct adaptation by a 
new program, some not. The Agency 
leadership has given the Program license to 
explore new methods and approaches to 
developing and procuring future human 
space flight and ground systems. We’ve 
also been charged with using the 
Constellation Program to do nothing less 
than reconstitute systems engineering 
capacity within NASA’s human spaceflight 
community, to smoothly transition the 
human spaceflight workforce to the next 
generation of capabilities and to lay the 
foundation of a program that will be cost- 
effective and sustainable into the far future. 
While remaining attentive to the lessons 
learned from current and prior programs, 
Constellation Program should lead the 
Agency in cultural changes—to re-invent 
how human spaceflight development is 
done. 

Meet Commitments 

The Constellation Program should meet its 
commitments; that is, do what we said we 
would do, when we said we would do it 
within the allocated budget, schedule, and 
technical requirements. If the budget is cut, 
let stakeholders know the impact to our 
schedule and/or technical commitments. The 
practice of maintaining unrealistic schedules 
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in the face of budget cuts should not be 
continued. 

Improve Spaceflight Risk 
Achieve an order-of-magnitude 

improvement in risk to crew and mission 
over that of the Space Shuttle. Current 
probabilistic risk assessment puts the risk of 
loss of crew for the Space Shuttle on the 
order 10 2 . Constellation should improve 
this to the order of 10 3 . 

Simplify Operations 

The Constellation Program should plan and 
require simplified operations such that 
operational costs are minimized, particularly 
with respect to Space Shuttle heritage 
operations. New developments for lunar 
and Martian expeditions are only possible if 
budget is made available due to decreased 
operational costs. Thus Constellation will 
only be sustainable if the operational 
infrastructure and workforce are more 
efficient than today. 

Recognizing the need to establish a program 
office co-located with the NASA program 
experience base, ESMD established the 
Constellation Program at the NASA Johnson 
Space Center in November of 2005. The 
following sections describe the decisions 
that were made in its formulation in the 
context of the guidelines discussed above. 

ORGANIZATIONAL STRUCTURE 

Constellation Program 

The structural model that most closely 
resembles the current mission is the Apollo 
“5-box” management structure 6 and was 
selected because it worked effectively. 
These five organizational functions are 
comprised of program planning and control; 
test and verification; operations integration; 
systems engineering and integration; and 
safety, reliability and quality assurance. This 
was adapted and tailored to the Constellation 
Program’s more evolutionary objectives. 
Constellation is envisioned to have 
developmental aspects throughout its life 
cycle in that new developments to support 
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the next mission will start in phases as 
current developments become operational. 
For instance, lunar outpost development will 
start after the low Earth orbit portions of the 
program are operational. The adapted 
organizational structure is shown in Figure 
1. Note that an advanced development 
function (Advanced Projects Office) has 
been added to the Apollo “5-box” structure. 
This organization houses research and 
development activities for ‘pre-projects’ 
envisioned to support lunar missions and 
beyond. Organizations outside of NASA, 
such as international partners and 
commercial partners, could be involved in 
these later phases of the Program 7 . 


The program was staffed with recognized 
leadership within the Agency (e.g., from the 
ISS Program, Space Shuttle Program, and 
Mission Operations Flight Director Office) 
and the contractor/DoD space community 
between November 2005 and March 2006, 
seeking project managers with 

demonstrated experience in executing 
projects and discipline-area leaders able to 
assemble strong teams, articulate a clear 
vision of the task, and integrate horizontally 
and vertically. 



A-Acang 
M - Matrix 



Marrayei 


Figure 1: Constellation Organization Structure. Program Management (first row boxes); the 
Program Offices adapted from the Apollo 5-box structure (second row boxes); Project Offices 
(third row boxes). 


Constellation Projects 

The projects that comprise the Constellation 
Program are listed in the bottom row of 
Figure 1. Table 1 describes major 
responsibilities for each project in the 


development and operational phases of the 
Program. 

Program/Project Integration 

We know from Agency history that our 

success depends on a strong program 
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leading strong projects. As soon as the 
program office was staffed, we began a 
process of negotiating roles and 
responsibilities between the program and 
projects. All recognized the importance of 
having a program office integrate project 
interfaces, as well as the importance of 
allowing projects maximum flexibility in 
managing their assigned element. However, 
a detailed examination of integration 
processes was necessary to truly understand 


and assign responsibilities. The program and 
project deputies conducted integration 
process decomposition in order to 
understand and agree upon ownership for 
each step in the integration processes. This 
understanding is paramount for 
implementation of hardware and software 
interface agreements and is a key element 
leading into the design definition phase. 


Constellation 

Project 

Lead 

NASA 

Center 

Function 

Developmental Phase 

Operational Phase 

Project Orion 

JSC 

Develop and test the Orion (CEV) 
spacecraft to transport crew to and from 
space. 

Provide Orion spacecraft. 

Project Ares 

MSFC 

Develop and test the Ares I (CLV) and Ares 

V (CaLV) launch vehicles. 

Provide Ares launch vehicles. 

Ground 

Operations 

Project 

KSC 

Perform ground processing and integrated 
testing of launch vehicles. Plan, construct 
and/or reconfigure integration, launch, and 
recovery services for Orion Crew Module, 
Ares I and Ares V. 

Provide logistics and launch 
services. Provide post¬ 
landing and recovery services 
for the crew, Orion Crew 
Module, and spent Ares Solid 
Rocket Boosters (SRBs). 

Mission 

Operations 

Project 

JSC 

Configure, test, plan, and operate facilities, 
systems, and procedures. Plan missions and 
flight operations. 

Train crew, flight controllers, 
and support staff. Coordinate 
crew operations during 
missions. 

Lunar Lander 
Project 

JSC 

Develop and test the Lunar Lander to 
transport crew to and from the lunar surface 
and to provide a habitable volume for initial 
lunar missions. 

Provide Lunar Lander. 

Extravehicular 
Activities 
(EVA) Systems 
Project 

JSC 

Develop EVA systems (spacesuits, tools, 
and servicing and support equipment) to 
support crew survival during launch, 
atmospheric entries, landing, abort 
scenarios, and outside the space vehicle and 
on the lunar surface. 

Provide spacesuits and tools. 

Future Projects 

To be 
deter¬ 
mined 

Develop systems for future applications 
including Lunar Surface Systems 
(equipment and systems for crew operation 
on the lunar surface) and systems for future 
human exploration activities. 

Provide future systems as 
needed. 


Table 1: Constellation Project Descriptions 


Agency Governance 

The Constellation Program is the first new 
program within the Agency to implement 
the NASA Governance Model that resulted 
from the CAIB recommendations 2 . In brief, 


the Governance Model provides for checks 
and balances between the program and the 
independent technical authorities established 
within the Agency. For the Constellation 
Program, the Program Manager (and staff by 
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delegation) have authority over mission 
performance, programmatic, cost, and 
schedule requirements. The Office of the 
Chief Engineer (OCE), the Office of Safety 
and Mission Assurance (OSMA), and the 
Office of the Chief Health and Medical 
Officer (OCHMO) have authority over 
engineering; safety, reliability and quality 
assurance; and health and medical standards, 
respectively. They also have the 
responsibility to provide informed technical 
recommendations on programmatic issues 
throughout all stages of a program life cycle. 
In addition, they provide an appeal path for 
program office personnel or line 
organization personnel who disagree with a 
program decision. NASA and industry 
standards, ranging from human rating 
standards to conformance to the metric 
system, are owned by the technical 
authorities. However, not all requirements 
in these documents are applicable or 
appropriate for the Constellation Program. 
It is the Program’s responsibility, with the 
assistance of the technical authorities, to 
develop and recommend a tailored set of 
these requirements. It is the technical 
authorities’ responsibility to review and 
approve the tailored set of requirements. 
Risk acceptance is the Program Manager’s 
responsibility, including the acceptance of 
residual safety risks that result from ground 
or flight anomalies, hazard analyses and 
FMEA/CILs tt However, the technical 
authority may appeal if they determine that a 
risk is unacceptable for flight. 

Decision Making Structure 
The Constellation Program uses a 
board/panel structure for making decisions 
that affect the baseline, as well as for 
making technical implementation decisions 
at a program level. An example of the 
decisions that affect the baseline would be 
anything that requires a change to a Program 
approved document. An example of a 
technical implementation decision would be 
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whether to approve a design modification 
requiring additional funding. The 
Constellation Control Board is chaired by 
the program manager; membership includes 
each project and program office appearing in 
Figure 1. 

In order to implement the Governance 
Model, the technical authorities are also 
board members on the Constellation Control 
Board. This avoids the ‘shadow 
organization’ that has evolved in past 
programs. These representatives cannot be 
program office personnel, nor can they be 
funded by the program. In this board 
structure, program office personnel (SE&I, 
Program SR&Q, etc.) are responsible for 
providing a recommendation to the Program 
Manager for their functional area. It is the 
responsibility of every board member, 
whether within the program or part of the 
technical authority, to ensure that the board 
is aware of dissenting opinions, that they are 
discussed, and that the dissenter is advised 
of the disposition. If an individual or 
individuals disagree with a Program 
Manager or Technical Authority decision, 
and believe that the decision poses a risk to 
safety or mission success, there is an 
established appeal path. 

WORKFORCE 

As noted in the Background section, the 
Constellation Program has been formulated, 
and must execute, during continuous 
operations of the Space Shuttle (through 
2010) and ISS. Moreover, we must be 
prepared to make best use of the expertise 
resident in the Space Shuttle workforce, 
when it becomes available as that program 
phases out. Constellation has developed a 
phased development program in anticipation 
of this workforce availability. This phased 
approach is described in more detail in the 
Schedule section of this paper. 


ft FEMA=failure modes and effects analysis; 
CIL=critical items list 
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The Program office workforce is comprised 
of engineers, scientists, and administrative 
personnel and was sized utilizing experience 
from past programs as well as guidance on 
availability of key personnel to support three 
human spaceflight programs at the Johnson 
Space Center. The initial size estimate was 
based on previous human spaceflight 
programs and was set at approximately 8% 
of the total program content. After the 
Program System Requirements Review there 


was sufficient experience in the office to 
attempt a reduction in the budget to only 
~ 6.5% of the total program content. This 
was based on expected workload and 
products and a better understanding of the 
program integration responsibilities. The 
Program team continues to track risks 
incurred with this funding level and to 
reprioritize work as needed to meet the 
program milestones. 


Ames Research Center 

• Lead Orion Thermal 
Protection System 
development 

• Program and 
Project analysis 
support 

Dryden Flight Research 

Center 

• Lead Orion Launch Abort 
System Flight Test 
development 



Glenn Research Center 

• Orion Service Module and Spacecraft 
Adapter integration 

• Ares Upper Stage subsystem 
development 

• Integrated Orion qualification testing 

• Manufacture Ares I 

Upper Stage 
simulator :* 

W 

m 


Goddard Space Flight 

Center 

• Communications 
support 




y\ 

Hi 

Jr 


White Sands Test Facility/White 

Sands Missile Ranee 

• Orion Launch Abort System 
flight testing 

• Orion and Ares propulsion 
system testing 


Johnson Space Center 

• Constellation Program 

• Project Orion, Mission 
Operations Project, Lunar 
Lander Project, and EVA 
Systems Project 


Michoud Ass’y Facility 

• Orion component 
fabrication and assembly 

• Possible Ares I Upper 
Stage, Ares V Core Stage, 
and Earth Departure Stage 
assembly and 
manufacture 



Lanele v Research Center 

• Orion Launch Abort 
System integration and 
landing system 
development and testing 

• Test vehicle integration for 
initial Ares I flight tests 




• Ares propulsion 
testing 


Marshall Space Flight Center 

• Ares Project 

• Lead Earth Departure Stage 

• Ares I Upper Stage propulsion 
testing 

Kennedy Space 

Center 

• Ground 
Operations 
Project 

• Ground 
processing, 
launch and 
landing/ recovery 


Figure 2: Constellation work assignments at NASA Centers 


Distributed Teams 

The projects are staffed by leveraging 
expertise across the Agency. Project work 
assignments at the 10 NASA Centers (and 
the White Sands Test Facility/White Sands 
Missile Range) are described in Figure 2. 

We recognize that managing a team 
distributed to this extent is a daunting 
challenge; indeed it is only now possible 
with current communications technology 
that enables real-time electronic meetings, 
single-source record keeping, and 
maintenance of the requirements baseline in 


a single database accessible by all program 
elements. All members of the workforce 
must use the selected electronic tool suite in 
order to make this distributed team work. 
Sage Advice 

Though NASA has considerable talent in its 
workforce, programs intended to carry 
humans to and from space are characterized 
by design, development and testing 
challenges which differ greatly from those 
encountered by the orbiting International 
Space Station or operational Space Shuttle. 
To reach back and capture launch and return 


Vol. I - Executive Summary 


Page 33 


















































Constellation Program 

vehicle experience, the Constellation 
Program created a ready resource - SAGES - 
Shuttle and Apollo Generation Expert 
Services. This contract provides a simple 
pathway to enlist the aid of retired experts 
from NASA’s past (e.g., George Mueller, 
Chris Kraft, Glynn Lunney, etc). 

Beyond review and advice, SAGES was 
created to transfer knowledge through 
mentoring. It is based on relationships 
between Apollo and Shuttle-era program 
managers and discipline experts, and the 
Constellation team. SAGES provides 
mentors on an as-needed, targeted basis in 
areas ranging from technical design and 
analysis disciplines, to ground and flight 
operations, to program management. Twenty 
four tasks have been initiated to date, 
including margins management; relationship 
between Level II program office and the 
Level III project office responsibilities; 
lunar lander requirements; test and 
verification planning; and launch abort 
design and operations. 

REQUIREMENTS 

The ESAS team had developed an 
Exploration Architecture specification and 
draft system requirements documents 
(SRDs) for both the CEV (Orion) and the 
Ares I (CLV). In lieu of an established 
Program office, the follow-on ERTT 
formulated, as its primary task, a 
requirement set consistent with the 
architecture defined by the ESAS team and a 
CEV SRD sufficient to support a down- 
select of CEV contractors in 2006 as part of 
the Call for Improvement (CFI) process. 
Thus initial requirements for the basic 
architecture, Orion, and Ares I were 
established at the time the Constellation 
Program office began work. The Program 
team had to quickly establish processes, 
roles, responsibilities, and team 
organizational structure to align an 
integrated set of requirements that would 
unite the elements together into a strong 
program that could integrate and execute 
missions. 


Lessons Learned Volume I 


Zero-Based Requirements Approach 
Requirements development was the linchpin 
for concurrent maturation of program cost 
and schedule. A zero-based requirements 
philosophy has been adopted in which only 
the necessary and cost-effective 
requirements are included. Projects are 
directed to “drive-out” unnecessary 
requirements, write requirements in terms of 
outcomes and not solutions or “how-to” and 
drive out non-value-added steps in achieving 
outcomes. This approach is requisite for all 
contracts and ‘in-house’ work. The need for 
data deliverables, reviews and 

applicable/reference documents is carefully 
scrutinized in order to be sure that these 
requirements are necessary, value-added and 
cost-effective and are required to achieve the 
desired outcome of a project. This will be a 
continual process not only in the pre-award 
phase, but also in the post-award 

administration of contracts. 

Evolving the Architecture 
With an integrated program team under 
development, several significant 
improvements to the architecture outlined by 
the 60-day ESAS team became apparent 
through trade-study and risk analyses. The 
Program base-lined the Apollo-heritage J2- 
X engine as the primary upper stage engine 
for both the Ares I and Ares V 
configurations. A cluster of five RS-68 
engines (common with the Delta IV) was 
selected as the baseline first stage engine 
configuration for the Ares V. And the first 
stage solid rocket booster configuration was 
lengthened to include 5 segments (rather 
than 4) for both the Ares I and Ares V 
configurations. Architecture requirements 
were also established for the EVA suit 
systems, ground operations and mission 
operations 8 . 

Program Requirements Reviews 
The Program embarked on a season of 
System Requirements Reviews (SRRs), 
commencing with a Program SRR in the 
Fall of 2006, progressing through project 
SRRs, and culminating in Program baseline 
synchronization in May 2007. The SRR is 
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conducted to ensure that the program 
requirements are properly formulated and 
correlated with the Agency and ESMD 
strategic objectives. Specifically, the SRR 
assures that: the high-level program 
requirements are complete and approved, the 
interfaces with other programs are approved, 
the program requirements are cost-effective, 
the program requirements are decomposed 
and adequately levied on projects, the plan 
for controlling changes to program 
requirements is approved, the approach for 
verification of requirements is approved, and 
mitigation strategies for addressing major 
risks are approved. After project SRRs, the 
program baseline synchronization was 
conducted to resolve discontinuities 
identified among project requirements and 
between project and program requirements. 
In January of 2007, Constellation gathered 
Apollo and Shuttle veterans (via the SAGES 
contract mentioned earlier) in a “greybeard” 
review of the program baseline to seek 
advice and management guidance through 
the early phase of the program. This advice 
is currently being integrated into the 
program, particularly in our approach 
towards risk management. We intend to 
continue involvement of our spaceflight 
veterans as we move forward towards 
program implementation. 

Projects are beginning System Definition 
Reviews (SDRs) at this writing, to ensure 
the readiness of the program for making a 
program commitment agreement (PCA) to 
approve project formulation startups and 
move into the program implementation 
phase. 

Safety, Reliability and Quality Assurance 

(SR&QA) Requirements 
It is the goal of the Constellation Program to 
achieve an order-of-magnitude improvement 
in risk to crew and mission over that of the 
Space Shuttle. Some of this improvement 
can be achieved through design 
improvements. The Ares I/Orion system is 
estimated to be much more reliable for the 
crew than the Space Shuttle, primarily due 
to its in-line design and incorporation of the 
Launch Abort System for crew escape. 
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Other improvements must focus upon 
changing the way we ‘do’ SR&QA. This 
centers around: the early identification of 
requirements driving safety and mission 
success, the performance of safety and 
mission success analyses throughout the life 
cycle, but early enough to influence design 
and operations, and an assurance framework 
that verifies that the system is designed, 
built and operated in accordance with 
requirements. 

SCHEDULE 

The primary schedule requirements for the 
Constellation Program are to develop the 
CEV (Orion) to transport humans to and 
from ISS by 2014 §§ , and to return humans to 
the Moon by 2020. These two goals lead to a 
phased schedule approach, illustrated in 
Figure 3 (through 2011). Figure 3 shows two 
primary elements of schedule execution: 
Initial Capability (IC) development and 
Lunar Capability (LC) development. The IC 
includes the elements necessary to deploy 
the CEV/CLV (Orion/Ares I) configuration 
that will support ISS, including the ground 
and mission operations capabilities and the 
spacesuits (EVA systems) needed for the 
crew. The LC includes the Cargo Launch 
Vehicle (Ares V), the Lunar Lander and the 
Lunar Surface Systems (e.g. rovers, habitats, 
scientific equipment). The current focus of 
the Program is development of lunar capable 
elements that support the ISS. Many of the 
elements of the IC now under development 
are accelerating the LC. For example, the 
J2-X engine is the primary engine on the 
upper stage of both the Ares 1 and Ares V 
vehicles. This aggressive development for 
the Ares I will provide higher confidence 
during the Ares V vehicle development. The 
five-segment solid rocket motor first stage 


§§ Reference discussion of confidence level in 
following section resulting in current commitment to 
field Orion and Ares I by 2015. 
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of the Ares I is common with the twin solid 
rocket motors on the first stage of the Ares 
V. In addition, the crew’s EVA and 
pressure suits for the IC are being developed 
as a modular single-suit system with 
capability to add/exchange elements 
necessary for the LC. 

While the continued operations of the Space 
Shuttle constrain the budget and workforce 
available to develop Constellation through 
2010, we also must prepare to make best use 
of the experienced workforce as it becomes 


available though the phased retirement of 
the Space Shuttle. Responding to that need, 
targeted activities in the LC development 
have begun. Requirements must be 
developed to a level to enable contract 
acquisitions in the 2010 timeframe in order 
to deploy and utilize the resident expertise in 
the Space Shuttle Program’s civil servant 
and contractor workforce to the extent 
possible. Initial concept development of the 
Lunar Lander and Ares V are underway to 
mature the requirements set to the necessary 
level. 






DATES UNDER REVIEW 1 

Figure 3: Constellation Program Roadmap through Fiscal Year (FY) 2011 
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The lower portion of Figure 3 illustrates the 
flight test program planned for the remainder of 
this decade. The Orion design incorporates a 
Launch Abort System (LAS) that would pull the 
Crew Module to a safe landing if necessary in 
the event of an abort during launch and early 
phases of ascent to orbit. While this system is 
based on Apollo heritage, it must be thoroughly 
tested prior to utilization with a crew on board. 
A series of flight tests of the LAS is planned for 
the White Sands Missile Range (WSMR) that 
will include both pad abort and ascent abort 
tests. In 2009, Ares I-X—the first developmental 
flight test of the ‘integrated stack’—will be 
launched from the Kennedy Space Center 
(KSC). Ares I-X will test the integration and 
performance of a simulated Ares/Orion ‘stack’ 
prior to Critical Design Review (CDR) so that 
resulting design changes could be incorporated 
before production of flight articles. Further flight 
testing at KSC is planned into the next decade. 

BUDGET AND ACQUISITION 
Budget Development 

The ESAS team had assembled a preliminary 
budget estimate for execution of the 
recommended architecture. In the spring of 
2006, the Constellation Program developed an 
unconstrained “bottoms-up” budget estimate for 
the purposes of establishing a “first cut” 
understanding of the drivers for costs and 
schedule from present to the lunar landing phase 
of the Program. This analysis provided the 
element break-down and the raw data for 
building a subsequent budget that was 
realistically constrained by Agency priorities 
and needs. By the summer 2006, the Program 
was able to establish the first budget baseline 
meeting Agency schedule commitments of 
deploying the CEV (Orion) by 2014, and 
landing on the Moon by 2020. 

These were updated in the Fall of 2006 as 
program requirements matured. Completion of 
the Program’s System Requirements Review 
(SRR—see Requirements section), provided a 
further level of requirements development that 
allowed for more refined estimates in the 
Agency’s FY07 budget development cycle. 


Confidence Level 

The history of human spaceflight is replete with 
examples of cost overruns due to confluence of 
under-funding, insufficient or poorly phased 
reserves, misunderstood risks and complexities, 
overly aggressive schedules, and difficulties 
meeting ambitious technical requirements. We 
have no illusions that we will not encounter 
these challenges; therefore the Constellation 
Program is pioneering within NASA the 
implementation of probabilistic techniques to 
assess the confidence level expected that the 
program can achieve given schedule milestones 
within the budget allocated 9 . Our guidance 
within the Agency is to maintain a confidence 
level of 65% that we can meet our schedule 
commitments within the allocated budget and 
technical base-line. Program confidence level is 
calculated incorporating project-level confidence 
levels, project-level risks, and program-level 
risks, along with assumptions on dependencies 
among the risks. The Program conducted 
confidence level assessments during the budget 
development process, and plans to refine these 
during annual budget cycles. This analysis is key 
to assuring that we maintain our commitments to 
our stakeholders and have underpinning 
rationale for dialogue when requirements 
changes to the baseline are under consideration. 
During 2007, the Program was allocated less 
funding than planned in the Federal 
appropriation bill. Since the Constellation 
Program proceeds as a ‘go as you can afford to 
pay’ program, this resulted in a 6-month delay in 
our commitment to fielding the first Orion crew 
vehicle and Ares I launch vehicle for Initial 
Operating Capability (IOC). This date is now 
March 2015, rather than 2014 10 . 

Acquisition Strategy 

As plans are made for the retirement of the 
Space Shuttle, NASA is assessing possible 
synergies to be gained between the contracts and 
acquisition strategies already in place. The 
Integrated Acquisition Roadmap Team (IART) 
has been chartered to map all existing and 
planned Space Shuttle, ISS and Constellation 
contracts and to identify opportunities to save 
costs, including life cycle costs, to utilize lessons 
learned and best practices, to address transitions 
across program phases, to maximize the 
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effective use of both the existing civil service 
and contractor workforce, and to facilitate 
strategic competitive opportunities. 

Where appropriate, the Constellation Program is 
utilizing current, proven technology in order to 
achieve safer, more reliable and affordable 
solutions. For example, the Ares I and the Ares 
V are based on proven systems from the Space 
Shuttle and Apollo Saturn V programs, enabling 
NASA to reduce development costs compared to 
designing and building an entirely new launch 
vehicle. This approach maximizes the value of 
existing facilities, certified parts, production 
tools and expertise. Common propulsion 
elements help reduce operation costs for a more 
sustainable exploration program. The 
Constellation Program has entered into sole 
source production contracts for heritage- based 
elements; ATK-Thiokol for the Ares I first stage 
and Pratt & Whitney Rocketdyne for the J2-X 
engine. 

Lockheed-Martin was selected as the prime 
contractor for the Orion development through 
full and open competition. The production 
contract for the Ares 1 upper stage was recently 
awarded to Boeing through full and open 
competition. Further prime contract awards are 
expected over the coming year. 

The Constellation Program acquisition strategy 
places an emphasis on the criticality of reducing 
and controlling life cycle cost in each acquisition 
phase because NASA plans to produce and fly 
these vehicles for decades to come. 
Understanding and managing life cycle cost is 
pivotal to the overall long-term success and 
viability of the program. 

OPERATIONAL PHILOSOPHY 

As noted in the contextual discussion in the 
Background section, the cost burden of Space 
Shuttle operations cannot be inherited by this 
Program if the Lunar Capability and the eventual 
Mars Capability is to be developed concurrently 
with Initial Capability operations. It is 
interesting to note that minimization of life- 
cycle costs, particularly operational costs, was 
an important objective of the Space Shuttle 
Program during its development 11 . This is not to 
point out folly, but indeed to illustrate how 
difficult this objective can be even under 


proactive management. We believe that we 
have the advantage of a much simpler system to 
operate, but are also cognizant that we inherit 
operational processes ingrained over a 30-year 
history. To that end, the Program has 
undertaken a number of efforts aimed at life 
cycle cost reductions. Examples are discussed 
below: 

Stretch Requirements 

The architecture requirements include ‘stretch 
requirements’ defined as those that enable 
ground and flight system supportability and 
reductions in operational life cycle costs. 
Modeled after the Boeing 777 development, 
stretch requirements specify a desired outcome 
believed to simplify operations. For instance, a 
‘clean pad’ concept has been specified to 
challenge designers to minimize services and 
interfaces required at the launch pad as well as 
location/access on the vehicle. Each service or 
umbilical (e.g. cooling) attached to the launch 
vehicle is thus challenged for relevance or ‘must 
have’ capability. The Ground Operations Project 
and Mission Operations Project are focal to 
manage the stretch requirements; these are 
incorporated into flight design via negotiation of 
Interface Requirements Documents (IRDs) with 
each of the flight projects (Orion, Ares, EVA, 
and Lander). 

‘Con Ops’ Development 

Constellation has developed a Concept of 
Operations (Con Ops) for operation of the 
program through its mission phases, in order to 
drive out operational features that influence 
hardware, software and interface requirements. 
This is a typical best practice in NASA program 
development. Design reference missions have 
been developed for ISS missions, lunar sortie 
missions, lunar outpost missions, and a Mars 
mission so that operational design drivers are 
identified early. 

Moreover, we’ve also initiated similar but 
perhaps unique con ops efforts for targeted 
processes that can influence life cycle costs. For 
example, the current practice of quality 
assurance in the Space Shuttle program is being 
bench-marked for efficiency improvements. By 
developing a con ops for how quality assurance 
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is conducted through the life of the program, a 
more efficient path to quality assurance may be 
determined a priori. 

Life Cycle Cost Evaluations 
Change evaluations to the program baseline 
must include an assessment of the life cycle cost 
impact of each change to the baseline. 
Constellation procurements—both ‘end-item’ and 
‘award fee’ types—include incentives to reduce 
life-cycle cost. 

Lean Efforts 

Lean six-sigma and Kaizen studies were 
conducted on some early developments, such as 
the Ares 1-X test flight. This has proven 
successful and the Program is seeking further 
opportunities to gain process time reduction and 
simplification. 

The ‘handoff between designers and the 
sustaining engineering and operational 
communities is being studied for efficiency 
improvements. Current practice includes 
overlapping responsibilities and designer 
involvement in post-design processes. Efforts 
are underway to identify and minimize this to 
ultimately reduce costs. 

Industry Advice 

The Ground Operations Project conducted 
feasibility studies under the Broad Area 
Announcement capability; requesting novel 
ideas from industry on how to streamline 
processing, launch and recovery operations. The 
concepts are intended to produce ‘cleaner’ 
techniques and processes in the belief that fewer 
anomalies are possible with simpler processes. 
Examples of concepts include new approaches 
to emergency egress system for the crew, 
isolation of the launch pad lightening protection 
system, and alternatives to hypergolic fuel 
loading to reduce processing time. 

If we are truly successful in driving down 
operations costs such that the cost per flight is as 
low or lower than we project, and we’ve 
designed the supremely operable system that can 
be processed, flown, recovered and refurbished 
with a minimum of effort, then we’ve opened 
the door to other acquisition strategies in the 
production phase that would not be open to us 


with a more labor intensive system. 
Specifically, the option to buy services as a 
commodity would be available so that we can 
then devote our expertise to designing the next 
Constellation element in the plan. 

SUMMARY 

As the long-term objectives of U.S. space 
exploration evolve, the near-term goals remain 
the same: to develop the flight systems and 
ground infrastructure required to enable 
continued access to space and to enable future 
crewed mission to the ISS, the Moon, Mars and 
beyond. 

The initial formulation of the program 
requirements baseline was completed in 
November 2006 at the Cx program SRR. The 
program is evolving within this structure of 
organization, requirements and funding as its 
foundation. A major challenge is to stand up an 
organization that draws on the best expertise in 
the Agency while maintaining primary focus on 
the currently operational Space Shuttle and ISS 
programs. 

The formulation of the Constellation Program is 
a robust system, based on the best of NASA’s 
heritage, and designed to evolve as technical and 
programmatic needs demand. 
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APPENDIX B. ACRONYMS 

APA 

allowance for program adjustment 

CAIB 

Columbia Accident Investigation Board 

CDR 

Critical Design Review 

CR 

continuing resolution 

Cx 

Constellation 

CxP 

Constellation Program 

D&C 

design and construction 

DoD 

Department of Defense 

ESAS 

Exploration Systems Architecture Study 

ESMD 

Exploration Systems Mission Directorate 

EVA 

extravehicular activity 

FY 

fiscal year 

HLR 

human lunar return 

1C 

Initial Capability 

IMS 

Integrated Master Schedule 

IOC 

Initial Operational Capability 

ISS 

International Space Station 

IT 

information technology 

JPR 

Johnson (Space Center) Program Requirement 

JSC 

Johnson Space Center 

KSC 

Kennedy Space Center 

LAS 

Launch Abort System 

LC 

Lunar Capability 

LEO 

low-Earth orbit 

LOC 

loss of crew 

MPCV 

multipurpose crewed vehicle 

NPD 

NASA Program Directive 
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NPR 

NASA Program Requirement 

NSA 

National Security Agency 

PBS 

President’s Budget Submittal 

PDR 

Preliminary Design Review 

PI 

Program Integration 

PMR 

Program Manager’s Recommendation 

RRA 

roles, responsibility, and authority 

S&MA 

Safety and Mission Assurance 

SDR 

Systems Definition Review 

SE&I 

Systems Engineering and Integration 

SLS 

Space Launch System 

SR&QA 

Safety, Reliability, and Quality Assurance 

SSP 

Space Shuttle Program 

T&E 

Test and Evaluation 

URL 

uniform resource locator 


Vol. I - Executive Summary 


Page 42 






REPORT DOCUMENTATION PAGE 


Form Approved 

OMB No. 0704-0188 _ 

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and 
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including 
suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, 
and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 


1. AGENCY USE ONLY (Leave Blank) 

2. REPORT DATE 

June 2011 

3. REPORT TYPE AND DATES COVERED 

Special Publication 

1 4. TITLE AND SUBTITLE 

5. FUNDING NUMBERS 


Constellation Program Lessons Learned; Volume I: Executive Summary 


6. AUTHOR(S) 

Jennifer L. Rhatigan,* Deborah J. Neubek,* L. Dale Thomas,* Charles Stegemoeller* 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

Lyndon B. Johnson Space Center 
Houston, Texas 77058 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Washington, DC 20546-0001 


11. SUPPLEMENTARY NOTES 
*NASA Johnson Space Center 


12a. DISTRIBUTION/AVAILABILITY STATEMENT 

12b. DISTRIBUTION CODE 

Unclassified/Unlimited 

Available from the NASA Center for AeroSpace Information (CASI) 

7115 Standard 

Hanover, MD 21076-1320 Category: 99 



13. ABSTRACT (Maximum 200 words) 


This document (Volume I) provides an executive summary of lessons learned from the Constellation Program. A companion document 
(Volume II) provides more detailed analyses for those seeking further insight and information. In this volume. Section 1.0 introduces 
the approach in preparing and organizing the content to enable rapid assimilation of the lessons. Section 2.0 describes the contextual 
framework in which the Constellation Program was formulated and functioned, which is necessary to understand most of the lessons. 
While context of a former program may seem irrelevant in the heady days of new program formulation, some time should be taken to 
understand context. Many of the lessons would be different in a different context, so the reader should reflect on similarities and 
differences in his or her current circumstances. Section 3.0 summarizes key findings, at the program level, developed from the 
significant lessons learned that appear in Section 4.0. Readers can use the key findings in Section 3.0 to peruse for particular topics, 
and will find more supporting detail and analyses in a topical format in Section 4.0. Appendix A contains a white paper describing the 
Constellation Program formulation that may be of use to readers wanting more context or background information 


14. SUBJECT TERMS 

Constellation Program; learning; management planning; NASA programs; research and 
development; schedules; production planning; risk acceptability; decision, management 

15. NUMBER OF 
PAGES 

56 

16. PRICE CODE 

17. SECURITY CLASSIFICATION 

18. SECURITY CLASSIFICATION 

1 19. SECURITY CLASSIFICATION 

1 20. LIMITATION OF ABSTRACT I 

OF REPORT 

OF THIS PAGE 

OF ABSTRACT 




Unclassified 

Unclassified 

Unclassified 


Unlimited 


Standard Form 298 (Rev Feb 89) (MS Word Mar 97) NSN 7540-01 -280-5500 

Prescribed by ANSI Std. 239-18 


10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 
SP-2011 -6127-V OL-1 


8. PERFORMING ORGANIZATION 
REPORT NUMBERS 


298-102 






























